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ABSTRACT 

Most programming in the Gamet system uses a 
declarative style that eliminates the need to write new 
methods. One implication is that the interface to ob- 
jects is typically through their data values. This con- 
trasts significantly with other object systems where 
writing methods is the central mechanism of program- 
ming. Four features are combined in a unique way in 
Garnet to make this possible; the use of a prototype- 
instance object system with structural inheritance, a 
retained-object model where most objects persist, the 
use of constraints to tie the objects together, and a 
new input model (hat makes writing event handlers 
unnecessary. The result is that code is easier to write 
for programmers, and also easier for tools, such as in- 
teractive, direct manipulation interface builders, to 
. generate. 

KEYWORDS: Object-Oriented Programming, 
Prototype-Instance Model, Toolkits, Declarative Pro- 
gramming, Constraints, Input, Gamet. 
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1. Introduction 

Over the last three years of using the Gamet system to 
create dozens of large-scale user interfaces, we have 
observed that the style of programming in Gamet is 
quite different from that in conventional object- 
oriented systems. In Gamet, programmers combine 
pre-defined objects into collections, use constraints to 
define the relationships among them, and then attach 
pre-defined "Interactor" objects to cause the objects 
to respond to input. The result is a declarative style of 
programming where the programmer rarely writes 
methods. Furthermore, the interface to objects is 
usually through direct accessing and setting' of data 
values, rather than through methods. 

The features of the Gamet object system have been 
motivated by the overall goal of the project: to 
provide high-level, interactive, mouse-based tools for 
rapidly prototyping and creating graphical, highly- 
interactive, direct manipulation programs. Because of 
the emphasis on rapid creation and easy editing, we 
have chosen to make the object system completely 
flexible and dynamic. Since the interactive tools need 
to be able to generate code for the interface and then 
read the code for later editing, it is easier to generate 
high-level declarative specifications. Because much 
of the look and the dynamic behavior in Gamet can be 
specified by supplying" parameters to pre-defined ob- 
jects, it is easier for interactive tools lo display these 
options in dialog boxes or intelligently guess them 
using demonstrational techniques. 



O0PSLA^2, pp. 184-200 
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In order to achieve, these goals, we have made a. num- 
ber of interesting design decisions which contribute to 
Garnet's unique ..programming style. First, Garnet 
uses a prototype-instance model rather than the more 
popular class -instance model. . In a. prototype-instance 
model, there is.no distinction between instances and - 
classes; any instance can serve as a "prototype" for \ 
. other instances. Garners model is, unique in that * it . 
supports structural-inheritance. This means that when . 
a prototype object is a collection (or 1 1 aggregate* ') of ~ 
other objects. Garnet creates- instances - of all com- : . 
poncnts; whcn the aggregate is instanced. Therefore,.,.- 
■the programmer can construct complex graphical ob- - v 1 
jects by dcclaratively listing -the primitive components- 
objects. It is not necessary to write creation or draw- t-.'-v 
ing methods. . 



Second, the "objects in Garnet are usually persistent; 
and long-icrm. For example, the . graphics model re- 
quires that there be an object irx_ memory correspond-., 
ing to "each object on the screen. This^means that the: 
programmer : cloes not have,.tp deal with object refresh, 
and allows the . toolkit to contain Wgh-JeypI support,' 
"'Me .selection handles. In many '.other., system si a 
single object can be used like a starriprpad "apd drawn- 
ih multiple places on the screen. ». ,. r . . ... _ a? - 



Tliirdrconstrairits can be'iised to/declare the 'relation^; 
J ships fc among the objects. Constraints* in Garnet are 
"tightly integrated with the object system, so^that any 
"slot* of any object can have a constraint" which cal- !: l : 
"culates'its value.' The result is that the. interface *tb ; -- J 
objects is "usually ; through data values/ which are ' 
directly . accessed and "set, rather., than through- - 
methods: ; Constraints ' arc used to propagate the^ 
changes appropriately. ^ --v ' 

Fourth, Garnet inborporates ; a novel input; model,. 

'which-' provides stand ard i: obj'ects " called : "Interactors" . 

1:6 - handle the 'most popular direct 1 manipulation be.- , * 

h'aviors. This is based'on the Model-View-Cdntroller: : 

idea from Smalltalk £8]; where the Interactbrs cor- s . 

respond tp the controllers, In Garnet, however, unlike: 
In Smalltalk and other implem'entaiior^" of this idea,. 

the programmer rarely writes new Interactor methods.:. v; 
'Instead, theprogjiainmer attaches, ^i instance "pf a prer;.-.-.. 
. existing" Interactof ^object to the/ graphical 'objects :- : 
"* using constraints, 1 and , declaratively \ . speqi fies any; 

necessary controlling parameters for the Interactor. 



This paper discusses these aspects, of Garnet, and 
shows the advantages of the- Garnet style of program- 
ming. Even though conventional wisdom for object- 
oriented programming is that writing methods is 
"good" and exposing the' objects' data is "bad," we 
show' that ^the Garnet -style is just as modular and 
provides just- as much information hiding. Further- 
more, there is some evidence that, at least for user 
interface programming, it is more effective. 

■ Garnet is a comprehensiveuseninterface;development 
environment in Lisp forX/Vl. 1 It. is in. the public 
domain (;and is freely, available.*.. Currently, over 30 

, projects around - th$ world are; : using the system 

- regularly. 2 The system contains, a number of features 

• that make~it well-suited for creating graphical user in- 
terfaces.- Unlike. other toolkits- which primarily supply 
widgets,. Garnet is specifically designed to v cover all 
aspects of user interface programming, especially the 

- insides of application -windows. ^ While there have 
ubcen a" number of papers about "Garnet [17] and its 

components -[-23; 15,24, 19], this is the; first paper 
-about -the programming styleV For a complete discus- 
sion of programming in 'Garnet, '-see -the 1 reference 

• manual [20]- v - - ': *—'r 

2. Related Work: ; ^ ' 

In \ht >: xtvms of the -Treatyl 6f Orlando*' [22], the 
Garnet object system is a prototype-instance model 
with dynamic, implicit, per-object sharing. It is 
dynamitr because* the^i^ changed at 

any time,- implicit because /objects inherit from their 
prototypes and/ \ybd canhof* explicitly declare how 
slots 1 are inherited (except t>y using constraints), and 
per-object because there." is no such thing as classes. 
The" "templates**; "(prototypes) [are 'entirely "non- 
-strict/' which means that ah instance can gain or lose 
slots at any tiirie.' These feahires make Garnet much 
like SELF [5] and. other prototype -instance systems 
[9]: However, uhlike SELF, Garnet rarely uses mul- 
tiple inheritance (although it is ffiow^.'an'd.we have 
integrated a constraint solving mechanism with the 



^Displ'ay PosLscript'ari^ Macintosh versions arc in progress. 

2 You cajvge? Garnet- by anonymous FTP from j 
a . gp ps . emu . e du. Change ta the directory , 
/usr/garriec/garnet / (note ihc ddub'le garnet's) and 
retrieve README for instructions. Or you can send electronic 
mail to gametics .emu .edu. 
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object system. Another important difference is that 
Garnet- encourages programmers* "lb clirccUy access* 
and set 'slots of objects, -whereas SELF prevents this : 
and only prdviaes meLhods. 

: Many systems have used constraints as part of an.ob~ 

* - jeet system [3], but. none is. as. general-purpose, or 
■ Mly-integrated as Garnet. Garnet is also the firstsys- r 
. tern to introduce pointer variables into constrain tsit 

(where the objects' referenced by the constraint can ;\ 
change). The first integrated constraint and object ^ 
T systenr-was Thing-Lab [2]-, which -supported :, mul ti- way 

* . .constraints. ThingLab was also-a prototype-instance^' . 

object: system. -Apogee [7] and* -Grow [1] are more;, 
closely: related to Garnet-in- goals- since ihey are user; 

* interface. toolkits.' 1 Also, like ^Garnet? ^they implemented 
. one-way ~ constraints.- Neither, • however^ uses con- 

* straints as^ the primary mechanism" for"' information 
. passing, so. they, both m^e extensive-use of methods. 

As vy as, m en t toned ; Garnet's : input model is- based :on,a?- 
■the Model-View-Gontroller; idea- from Small talk.[8j.r:-r' 

Jr Other ; attempts tc capture, interactive -behaviors „in- - 
Clyde the, model used by graphics standards, suchras;; — 

. PH1GS, GKS, r GGI^GORE, etc., ; wtiich identifies fivei — 
or six basic input types (e.g., locator, stroke- valuator,; . 
choice, pick and string for PHIGS). This is based on 
a model by Foley and: '"Wallace [6;]. Unfortunately, 
this .model" has proven unusable fop -modem .user inter^: 
faces [12].. \\ , ^ ( _, \ ^ r. ; , 

The current objected portsVaiStiyite?rn. is a complete^ r ; : 
redesign and rewrite of,^ .Gor^tVystem [23J. Coital 

* was . implemented in^CLOS^ but was. abandoned be-, ,> 
, cause it was too slow and inflexible in ' Like ; 
Gamet, Coral' provided, a declarative" syntax' for qb-> ;: : 
jects arid constraints, but ft was not. possible, to modify 
objects .once" they had^beeh created. Coral used a con- 
ventional ^class-insLance ...model, t rather 'than the-:.o;r: 
pibtbtyj^ ' Ii also re-;v:.;\ 
quired' tfiat^ .be "parsed" to search for ob^i 
jecrreferences^ whicK limited the kinds of constraints'' . 
thaf c6'uid ^ ^The current Garnet' .constraint- 
system 'does" not heed to parse constraints because nti* 
dynamically determines the dependencies when the^r; 
constraint is. evaluated.. <5oral did not provide for anoc 
bitrary pointer variables* in constraints like Garnet^ 
does now; and. it used' active .values; which we have;: 
found to be. unnecessary^ in_ Garnet \viLh; fully fun<x.s 



_ tional constraints. Coral had a special -purpose 
- mechanism for constraints oyer* lists' of objects, such 
as the items 1 of a menu. For example;' you could 
specify a constraint for the 'cop of the first item and a 

- different-constraint for'the>est of the items. This is 
not needed in Garnet due to the support for arbitrary 
code in constraints (you can just use Lisp's looping 

- facilities); The create routines in Goral were specific 
; to ^ eadh- class; rather than a generic function that 

:r ;' would work for all classes. Other important problems 
-with Coral were that the declarative technique did not 
support'thariging objects after they were created, and 
it was 'not Available to interactive editors. Therefore, 
r a- separate procedural mechanism was supplied. In the 
current Gairfet, : the 1 declarative " and' :: '/procedural 
mechanisms have equivalent power.' - r - * ,j 

3. The Prototype-Instance Object 
Vl Model ; [ - ; - - - . 

GaYrtet object .'system Implements; the prototype-^. 
*^^ c ^ jt 1 ^?! I^U'^PA supports completely dynamic t 
redefinitibn of prototypes 'with "automatic change 
[^P ro fes*tiQii l^^tt is ho distinction 'between in- 

^^^^"^r^^?^ s;; m y ^ ns ^9^ ^} ^iy^ as a.- : 
" ' ^ ;Rrot6tjpe^= for' 'other instances; ^^'"data and 
* Wethods ' aHe : st6ted'in' "Slots'; * Xscp^tifnes called V'* 
•'fields'* or ' ' instance Variables 1 0- " Ah iristahce can ; 
: ,.., a <*4 ?ny number of new slots, aqd .slots, that.-are not . ^ 
P^^^^^^^Jpl.^^nstance inherit r the values. from its J 
,prototyj^ ^ ft^'iiiite^ - : 

. i dynami caliy , ; as an object can add or rernoye slots at 
r _any time. ; between -.data and 

',\'nietti^ type ; of value, 

r. and in^C^mrnon jLisp,. V fuhctiqn, is just^i...type of 
yal r U0. . TTiis ; allows the methods' that' implement mes- 
" sages to change dyhamicaliy f; whi ch i? np^pbssible in 
conventional - object systems 'like Smalltalk.* The 
..ability ;to^ dynamically, add, dplete, and. modify 
, . methods t has' : prpyen ■ im po rtant in graphical interface 
. rbu.ildcirs since ; they, .need^ to, .temporarily, .insert their 
. ,p wn .'methods, during '/.build* !- mode r and then.; retract 
^then^ during ''test' 'mode! " ,- : ^ * n . : \\. 

: ^A1I„ objects are 1 ' created' 'with .the" st^ard liinction 
I ^X^^.~iAsHance 4 which j^es^^pptional name 
J^jtie fey bbjecC'an optional' object, td be used as a 
P^ t0 }yP^. ancj /a'lisf b^slbts^^d 

SlbV that are not mentioned start ' 
;biit using ' &e 1 inheritfed^ deTaul "t " vsJue^' from the 
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prototype:(which can- be changed later). Slot names 
" start with colons, and can- contain any number of 
printable characters (e.g., : left r ' : interim- 
. selected, :obj-over). In the following ex- 
ample, the rectangle named my-rect will inherit the 
':top, : width, and : height from the prototype 
rectangle: 

; create an object named rectangle inheriting from nothing. 
(create-insunce 'rectangle NIL 

' (:top 10) (:left 10) ; specify values for some slots. 

*•-(: width : 20) height 25) (:color black)) 

7 create my-rect inheriting from rectangle. .».-;•_ := 

(create-instance 'my-rect. rectangle .. - 

(:left 45) (:cp,lor blue)) ; override two slots. ' ' 

' Setting an .'object's slot with a value , automatically 
creates "the slot, if needed. This makes it extremely 
easy to associate any piece, of information with an^ 

""object, since slot names do not have to be predefined. 
' For example, jflie following will create a new slot in ' 

" rectangle: . 

(s-value rectangle :perimeter 90) 

Because my-rect inherits from rectangle, it will 
also now have the new slot. 

There is a special kind of object in Garnet called an" J' 
""aggregate'' whichis^a collection of othenobjects. '^'^ 
unidj'ud* feature, of Garnet .is, .that whenever an instance 
is made of an aggregate.. Garnet automari pally . creates 
instances of all its .components, and .links them"' 
together appropriately. This ".stmctural. inheritance''' . 
' is an extremely powerful abstraction, because. it frets' ^ " 
" the user from having to know whether an object beings : * 
instanced" 1 is a,primitive object like rectangle or a . 
composite like button; the create-instance call is the 
same. 

For example, a button might 'be ' cpmpos^d qf three 

rectangles and a text. object.' c The ^programmer can T 
' declaratively list these as pari of a button, as shown in' 

Figure "l. Then, when the us er^cjeates.my-^biittonl- 
~ tising button as the prototype/ Garget automatically 
' creates instances of the three rectangles and the text. 

Of cours^, any of the parts could themselves be ag- 

- ■ gregates,, and the instancing, would be applied .recur- 
.'. sively.; ... Constraints (described -below) are. used to 

- declare how the properties of the components ;are con-' 
. t nected; . ... ^ . . • * . . t : _ j\ o 

. ) An importarit innoyation .in Garnet Js that cflits made" " 
: Ltojhe prototype arevautpmadp^ly/efl«cted,in,^ in-* " 
' stances. For example, if the color of fill-inside" ' 




V: - • :^,i.i«J**t>* 1';. w. 



. (create-instance /-button aggregate 
..(: parts. . . " • '\ ■ - 

*' { C = top-edge rectangle .,...-)' : white left & top edges 
( : bottom-edge rectangle "1. . . ) ; 'black right &. bottom 

{z fill- ins i decree tangle )... ; grey interior , 

(r'label text ... ; string inside button 

-.V ^ •-• \ ( : string "Label" ) ) ) J ) * 

(create-instance ' my -button! button 

(:left 100} I: top 5) (: string "First ^ ) ) . 
"(create-instance *my-button2 button_ 

(:left 100) (*tbp 35) (: string ''Second")) 

(create-instance ' ny-butt on3..but t on . * * . ' 
(:left lC0)(:wcp 65 J ( :'s tfing "Third")) 

(b) * ' : ■* * " 

Figure 1: , r 
'(a) A -button (shown on the left) and some instances created 
from iL' (b) The- outline of the'button's" aggregate-structure 
and the code to create the instances.: . * ' 



were changed in butt on, it would automatically also 
change-irr my-buttdnl arid all the other instances 
(see" Figure' 2). More significantly, if -a 'part' is added 
"or rem bvid 'from the prototype, then Garriet will add 
or remove the corresponding object from all in- 
• stances: For 'Example if top-edge was- removed 
from button, then" the -appropriate rectangle would 
also" be' removed'fro& rny-but'tonl and the other 
instances. Garnet stores pointers in each. prototype to 
all instances to support these operations. 

Similarly, if the programmer wants 'to create an object 
which is a slight -imbdificatiorf of an existing -object, it 
is only- necessary' to- override "the divergent parts. For 
example, the programmer could have left-trie existing 
button prototype of Figure 1 unmodified, and 
created", a new" type of button that 1 looks like Figure 2 
by specifying: ' " . it 

(create-instance- 'new-button button - 
( : parts - ^ - - - * • „ - *" ' :± ■ 
( ( : top-edge : omit)' ;dont warn the top-edge rectangle. 

( : fi-11 -inside -:moai*fy - " 
..... ; jusi change the filling-style property. 
--i-' " (: fillipg-styie light-gray)) 
v.."- -t; ;boliom-edge and : label are unchanged. . 
) ) ) 
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Figure 2: 

When the color of the fill-inside rectangle is changed 
to Lght-gray and : the top-edge rectangle is removed From 
the button prototype in figure 1, these changes propagate 
automatically to theinstances; " • '" ' : '- : ■ ■ 



In a conventional object system, the programmer 
would instead be .required to rewrite the entire draw" 
method (and probably the- erase- and many other 
methods as -well-), "."In Garnet, only The specific pans to 
be changed need to; be mentioned; and only in the ob- 
ject definition. 

... A yery significant advantage.of this technique is that 
...'it is. possible to. provide graphical, .;inte.ractive tools 

that will create the graphical objects.- For example,.;' 
.-. Lapidary [15]. allows programmers -to draw -pictures oiC' 
■ ; new widgets (like the. .^buttons above). and., of new'"" 
. . appicatio.n-specifjc prototypes. , ; The . interface of '. 
.Lapidary is much ... like a, conventional drawing "\ 
program like MacDra w." The programmer.can -specify ' ^ 
which, slots wiil. be parameters, (for the button, they 7 "' 
might, be.' the position' ' and string); •' Interactive be- / 
nayiors .a^d. relationships Vmong the components can. ' ' 
; ^.be <? efin ^ : Because! all objects have! the same 
structure, .Garnet provides 'a built-in routine, that will... 
• save the objects to a file [21]. The contents of the file ! ' 
is simply the declarative code to create the objects, as. 
in Figure . 1-b, ..Therefore, ..this file. ..can be compiled' .. ' 
using the. .standard. Lisp, compiler. ;and ; the standard "■, .. 
Lisp load routine, is- aU ■ thatis needed. to readin the.' '...' 
objects; . . . 

Therefore.Xa'pJdary; can ..'simply .call the standard save ' J "' "' 
routine to write the created objects' tea file Jnstead of ' 
having to generate., code Jor r the/.meuSods;to' create,' :: 
d L raw -.. an f?, the objects, and for handling input 
events. V/ticn the appl.i cati'on"w ants ; these graphical 
objects to appear'atjnin^u^e,' it only needs to load the 
file, and createrinstances of she prototypes supplying. "■ . 



• .the appropriate parameters. Note .that.unlike other in- 
teractive interface builders,, such as the NeXT Inter- 
face Builder, Lapidary allows the designer to define 
entirely new objects, not just choose pre-defined ob- 
,. jects from a palette, The. various features of; Garnet's 
object system make this much easier to implement 

' f2i]. ; 

Since edits to aprototype are-reflected in its instances, 
' .it is even possible to interactively -change the ap- 
pearance of objects while, they are being used in an 
application, ;When Lapidary or a similar tool changes 
1 the prototype, all of the instances are updated im- 
mediately, even if they appear inside of an' application 
• that is currently running; ' This helps achieve the goal 
of making Garnet useful for rapid prototyping of in- 
terfaces, since the designer can' see the results of the 
• edits in context.' »i n a classiinstahce- model' or any 
method-based object system, if" Would 'usually be 
, necessary to stop; and -recompile io see the results of 
edits. 

One claimed disadvantage of the ' prototype-instance . . 
model; is speed, since every slot acbesV and" setting 
' might require a search up 'the inheritance' 'hierarchy to , 
fmd ^ sfot However,' through iirlpierhentation tech-?" 

• niqucs such; as caching 1 , we "have significantly im- f ■ 
; proved the performance of Garnet. Thu£>ven 'though ;• 
. '.' C^net-oiDfers dynamic inheritance, constraints,- and P 

-automatic ; constraint elimination (explained below), it 
-only takes '17.9 microseconds to ia^sY'slot. (on a 

• SPARCS'tation -. I , ' ' using - Allegro Cbmmdh Lisp 
: v4.0.1); ' • • - : • ■•• " -■■ • •• v 

4. Retained Objects 

Ar }other ^.important feature, of Garnet's .object system 
' is teat -most objects' .are .VMpng-terrn^/' Vtjniike other 
fe 'Aie in Garnet to repeatedly al- 
locate and disp'dse . bif o^ec^..';M6st objects afe, used 
' to; repres'eht ap^icatioWlirfo'rmadpn,; graphical dis- 
plays, or interactive behaviors wfficri^ persist.'" . .' 

; F6r- : example, -all graphics^ use a' ''retained-bbject 
model" (sometimes called "stnictbretf 'grapHcs''* or a 
'•'drsplay^list '~')\ -This means 'mat- for every graphical 
object on the screen, there is a corresponding object in 
I ?. e S\°fy- .^e/efore, to make something appear pn the 
screen, the programmer 'creates instances -of graphical 
-objects and;adds ; tfeirf tc/ a window. 'A "significant 
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difference from other systems that supply structured 
graphics, such as CLIM[11] and Interviews [10] is 
that there is no* way -to avoid -using the structured 
• graphics in Gamec all graphics must be displayed by * 
attaching instanc'es'of objects to windows. 

As an example; ."to . display ■ my-rbuttonl or - 
.my-rect, the programmer can create an instance of 
.a. window and add these objects: . : * 

{create— instance 'my— Window window) "> t / 
(addr components my-window myrbuttonl my-rect J 

This " will cause the * objects", to "be . displayed. ^ 
Prototypes can also be displayed, smce there is no dis-— 
unction between prototypes and instances. Therefore, 
the button that says "Label" in figure 1 is the actual., ; 
prototype for the instances. 

'"In a. similar way, Interactor objects which control be- ;.. 
hayibrs ; *(d^cribea\ below) are also' allocated and at- ; • 
tached to ] graphics^ ' Furthennbre, the data thiat 
describe the information arid state of the t application ; 
are often stored as Garnet objects. Thus, our tech- • 
\ niques are not just limited to the graphical .user inter-;;'- - 
' face part of the application. , ].\ 

' Iri order to cliange*-any propeny of an object, it is only; - 
necessary to set the appropriate slot, : and Gamet wiit:/^ 
propagate- the' change' appropriately/ For example, to- - 
change the string-of my-buttohl, you could use : 

~ ~ lt (s-valu : e ^iny-buttonl rstring "New : L'abel " > ' /!Vr:? v ' 

? This implemented usirig a^special demon procedure 3 

that : can be 1 associated with each object. This demdn 7 . 
" will be * called "whenever any : slots « of the object - . 
; changel For "graphical" objects ih Garnet, a built-in ■ 
demon is used which automatically insures that the 1 " 
appropriate graphical objects on the screen are 
redrawnr The graphical update algorithiri attempts to 
iriiniriiize 'the/nurriber of objects that are redrawn by 
"first determining .all pbjecis r that change" and .all ob- 
jects that intersect them, and' then drawing only those - .. . 
: objects jCfrpm back to front), using ah appippnate clip- - 
Jpirig region. A' differehX demon is used for Iriteractor : . , . 
6bjects'/_and applications^ *can', supply tlieir own 
. demons fpr appiicati c 

The 'advantage * 'bf-'the'-retained^bjeibt* model -is that ., 
v programmers are freed from : many*of the maintenance ^ 

"tasks they would have in most other systems. There ; ; 

c- is' never' a 'rieed/to -write "or 'call* cre f at£', in-r ;: 
itialize, draw, or erase methods. When a 



complex applicationrspecific 'graphical object is 
desired, the programmer uses: the declarative syntax to 
list all the component parts, and then creates instances 
and adds them, to the appropriate, window. . Of course, 
the prototypes themselves' can" also be created 
dynamically at run'.time. When objects are to be 
• -changed, Garnet automatically determines what must 
be redrawn.- Using: the same mechanism, Gamet 
handles window scrolling and refresh automatically. 

Of course, the primitive graphical objects, such as 
-rectangles, lines and text,* use draw methods internally 
-to display uSemselyes^on the screen. Other internal 
methods, are used for handling refresh arid for asking 
: objects whether .they : ¥iei under the mouse.: However, 
. since Gamet supplies, ijrimitive object for each kind 
-of . drawing operation in the X Window System, any- 
thing .that can be d'rawn^ini X.can- be'^created by com- 
. oining instances of Garnet's graphical "objects. There- 
fore, the programmer ean-s'irhply combine "the built-in 
" graphical objects, and :" never ^ -needs to *write new 
"methods. - ■ v ■ yr r y , • ; -~- J g& 

' Another .important advantage ^pf the retained model is 
[ that the toolkit pan provide buUt-h* "utilities for many 
Vbf the common vfunctions, ^ce all data -tises a stan- 
dard . structure. . iFor \ example,. ; G arriet . provides a 

widget which dispjays the popular square "handles" 
-around": graphical objects, for. selection, rmov-ing, and 
^growing themV ;i Tftis work's because the -handles can 
'reference the refairied, graphical objects to know what 

is on the screen, and how to modify tihem. Similarly, 
: there are built-in routines, for creating, 'duplicating, 

deleting," moving; growing, .arid printing objects. 

Thus, application developers do riot 1 heed to write 

code for any of this. 

The primary problem with the . retained object model 
is. the potential, for. enormous space, inefficiencies. If 
there. are ; 10^00$ objects qh thg" screen, there must be 
10,000 " objects in memory to . represent , them. We 
have taken a number, of steps, to overcome this 
"problem. r .AsVjih the. Glyphs in r .lhterViews [4], we 
. remove uhneeded information from - objects. For ex- 
. ample./we can remove large numbers of unnecessary 
constraints^(see below). However, unlike Glyphs, 
each object in Garnet,, stili keeps information about 
where it is located : on die .screen.-. Second, if there are 
a large number of nearly identical objects, such as the 
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squares in a bitmap editor ("fat bits"), the lines in a 
map or rnesh (Figure 3), or the dots in a graph, then a 
■ "virtual* aggregate" can be used that just pretends lb 
-create an -object .for each graphic. The programmer - 
provides a prototype object; and .the .virtual aggregate 
simulates creating an instance.foneach data' value, but 
- actually .does not allocate any- objects in mfemory. It 
still appears to the rest. of the code, however, that 
. there is an object for each- value; Using these tech- 
.niquesv people have .created /quite, large applications 
using Garnet. 




- Figure 3r ' • '* 
A mesh "created , using a- virtual aggregate' for the polygons 
and another viru^a] [ aggregate; for the^square knobs*. For the .s.- 
polygons, the virtual., aggregate! : is. passed, a prototype for sT.,.' , 
polygon* and an array "containing the" list "01* points and the 
color for each polygon. - r Tri'e virtual aggregate then 1 pretends - . j 
.to allocate, an ■ object "for.each -element of the array, but'.-':.; 
actually just draws the /prototype object repeatedly, (Pic- 
ture, courtesy of Kenneth "Mefisner of GeneraJ.. Electric'" 
[13].) ■ 'v. - ' ■ 1 v : - 



S.'Cahstirainfs ~ v ' -." ; " - " r - : - - : - 

An important 'feature of Garnet Js that any slot of any"'- 
object* can contain a constraint instead ^of ia normarV'* 
value. "A -constraint* is aVelationship 'that' is declared- 1 
once and then; maintained automatically by the sys- 
tern. For example#nstead of making one "£ntlpoint of 
a line be (10X5), : a programmer can define it to 1 be the 
same Jas "the' center- of the left edge '6f a" -rectangle; 1 : 
Then trie system' will change the value* of the erid point ' 
aubrnaticall y -whenever the rectangle mo vds: The - 
syntax 'for i^ferehcing slots of objects in' 1 Garnet is' - 



(gv object slot), where gv stands for "get- 
. .. value.": - : 

: Although many other research systems have provided 
constraints, Garnet is the first to truly, integrate them 
with the object system and tomake them general pur- 
pose. Constraints in Garnet can be any Lisp expres- 
sion. " An. important result of these design decisions is 
that constraints are. used throughout the system in 
many different ways. For 1 * example,- Garnet's im- 
plementation of a Modf - radio button widget uses 58 
constraints "internally, and the. Lapidary, .graphical 
editor, which is^a large and complex application, con- 
tains 16,700 constraints." Of course, many of these are 

'only evaluated once, and. may be eliminated, as will 

' be discussed later/ '"\ \ 

Since they can contain arbitrary code, constraints 
" might be thought to.be like meftodsVand, in fact, they 
serve: a similar purpose: to define the operation of ob- 
jects.' However,' the impoftanL pdint is that program- 
ming' with constraints is a different style than pro- 
* gramrhing with methods, m the same way that pro- 
' gramrhirig' with'methods is a different Style than con-, 
vendonal procedural programming. For one thing, 
qonstraints are automatically , evaluated when, neces- 
: sary, rather. than requiring the programmer to invoke^' 
.tftem at r appropriate ^ are . 

' declarative, In that they, compete the". yMues. of vari- j . 

ables (slots) based on values of other variables, and - 1 
vdo not have side effects., Finally, by focusing pn data 
>, values, , constraints -rnake ^progr^mming ^more data 
oriented, rather than procedure .oriented. Section 8 
discusses why constraints provide more information 
hiding -than conventional methods. 

One obvious use of constraints is to.tie parts: of com- 
posite objects together. When tJhe programmer col- 
lects* together a set of objects ^to' make a composite, it 
"is" necessary to specify tow "Jh'e pans relate? " '"Garnet 
provides a declarative .syntax so rhe ' programmer can 
simply list the'relatip^Hipslof the parts. ' Ah ' innova- 
tion of the 'Garnet constraint systexn is that* the objects 
can be referenced through pointer variables [25]'. This 
is used to'allow the code of the constraint to be inde- 
pendent ofjhe specific objects used for the parts. In- 
steady the constraint, will reference .the object using a 
^ ' path V. through.'^ ,'Fbr ex- 

ample, in the .button of Figure i f .the bottom- edge 
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rectangle can refer to the width of the text object, 
using: \' c [\ 

(grv SELF rparent :label :width) 

As shown in Figure 4-a, this starts from " the 
bo ttom-edge r rectangle, goes up to the parent ag- 
gregates-down to the label part, and gets the 
: width from there. .^Thus, the width of the 
bottom-edge will be the same as the width of the 
label. This will work in.ihe prototype, as well as in ] .. t 
all instances, since Garnet* sets pointers to the ap- , 
propriate objects into the slots : parent, :fili-„ v 
inside, : bottom-edge, etc. This makes it easy, 
for Garnet to create instances of the entire aggregate 
(including the constraints), since Garnet does not need 
to'eciit" the constraint code. Because this style of con- 
straint is quite common, we provide' an abbreviation / _*y 
of 'Xgfv iSELFJ a*s"gvl. Figure 4-b shows the cor>>;y. 
straints-uscd to tie together the parts of the button of v; 
Rigurel. *"■ " ' -:.r.\ • 

These 'constraint are fairly simple, and are rcprc- :; , ^ 
sehtative of .the. s majority of the constraints usedjn ^ 
Garnet However, some objects have quite long anfi , ( . . . 
complex constraints. -For example,, the aggregraph . . . 
object'-is-a- special' type of aggregate that displays -its fj ^ 
compqnents/as"a -tree or graph, and it has a very large t 
constraint that corriputes the graph layout information,,. ^ 

Another important use of constraints is to copy values 
and parameters around: For example, the Motif but- ^""^ 
ton prototype takes the string label, the color, and the ^ V 
position 'as parameters 'fymohg.' others). These',' ^ . 
parameters are supplied as values in the slots of the / J 
top-level -widget aggregate. When the object is 
created, the* programmer can specify whichever slots 
need different values and the rest are inherited. Of - t 
course, any L value can;-' be changed . later -while the^ ... 
widget is displayed, if desired. ; Note that this'-is quite 7: . 
;different.frorn : a "Conventional system iixzt requires the c 
fidget creation iriethod to. take a. large parameter lisj> - 
A v/ith r aU-possible values ;to : be set, ; and therefore re- - , 
quires a- custom 'creatibn method for" each 'object. In 
"Garnet/, the standard; create-instance 'routine is 
used/ for all objects, and .it can : be ;usedrtQ set an ar- , 
- bitrary riumber.of slots, .iv* 3 - > 

-Although "the slots which sen;e" as' : parairoters are in .. ' 
"jhp jop-leyei bufe iht^e.v.aiues to ac-.. 

tually take effect they must be copied down to the 




(a). 



(create-instance 'button aggregate 
" : {•: l"ef £ c -2i)> - *' ' -These orelKt - ' ' ~ • : - ' 

.(.it'op 20) r . ■ ; ^ J } parameters to » t . - : » 
" '(: string "label") ; ' the ballon. 
(: parts' '•■ "•. ^ ■ - - - ■'• " ■ - 

[(: top— edge rectangle 

(:left (formula (gvl :parent :left))) 
' ' { z €ap ' ( formula* (gvl : : parent- : top) j )• - 
..(; width (formula,- r . ~ , - ■ • ,■• -• ■ 

*=( + (gvl- : parent ' :labei' : width) /B) ) ) 
* ''( rhftight '.(formula '■ " _ — " '-, 

, ... (+ (gvl ^parent ^: label rheight.) 8),)) 
'(: color white) ') * ' . ; • 

(: bottom-edge rectangle ( ; « ^ , "■; / v_ 

(cleft (formula* *'(+'' 2 (gvl -parent :left)))) 
. . ~{:top (formula- {+ 2 (gvTiparent- :top) ) ) ) 

• (: width: -(formula ' , ... • . . u v 

(V J 6 (gvl : parent : label" : width) )) ) 
; . ' ; • f ( fVheigh t ■ ; vf o rmul a - . ~ I/- " ; ; ■' .« '•. *ir '. " "« 
s S . (gvl : parent : label heigh t) ). ) ) 

• (•: color '-black J"-)'\ ; " *• ' - - . :■-*■> 
: ■ ( : f ill-ipsi-de. rectangle,: ■ ' ; 

] '_^\'( : left" "("formula" , ' . . 
. :. " *.- (^vl" ilpa-reht"- : bottom- edge' :left) ■■)'■) 
. .• .(-:xop.. (formula — . : , * . 

J *" "'(gvl" : parent ' : bottom-edge*" : top) )) 
C^'f . t (':Jwi<ith .(-formula . -".^C . " ■ . 

(- jgvl. rparent :bqttqm-edge :^width) 2))) 
- (Vheighx' (-formula _i " " 

-C- (gvl .: parent- .: hot tern-edge height ) 2))) 
(: color . gray ) f ' 
.;{.-:' label^'t^xt • ^ "V ; - • : ' J ' '' 

.^(:l : eft {.formula, , -• », . 

* ' ^(center-x l (gv 1- :"parent : f ill-i'nsi'de) ) ) ) 
( :;top (formula j- V", - v ; : 4 "v. 

(center-y (gvl ;pareht : fTill-inside J ) ) ) 
(rstring (formula , (gvl : parent rstring) ))))) ) 

- .r.,-" ..: ■ ; 

: »v uv: i / » ^gure^:^: • ,r ^' 

(a) The.sLruciure of the. qbjeqts.in. tbo. button. of^Figure 1 
^showing the references^ .(b) IT}e"corriplete code, used to 
produce the button: This" l sho^vs't&e Constraints- which put 
^the: graphics in the- correct places 'and -copy the parameter 
values to the ; parts.- i- ; - ; ^ r > > - ..is... , T 



appropriate" places 4 in the corhponeints. For example, 
the-string valirc is specified at the 1 top fevel in Figures 
• 1 arid 4-b, but it' is needed by the text object* So there 
is a constraint f m the text object tHar 'copies the value 
of the paranieter. J Of course, sines constraints can be 
arbitrary Lisp code:, the values can f be 4 traiisformed ar- 
bitrarily as needed. Since constraints are used to 
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propagate the values, the objects do not have to do 
- anything- special- to allow- changes at run-Lime: if one * 
of the parameter slots is changed, the constraints 
automatically-propagate the change appropriately, and 
the update algorithm will make sure the object is then, 
redrawn. - ' . 

An- interesting observation ..about this use of cqh- 
~ straints is that it allows arbitrary, delegation of values,', 
not just from prototypes. Any slot can get its Value 
from any slot of any other object through constraints/' 1 
Therefore, the constraints can be used as a form of : 
inheritance/ Or'rouzse/const™^ '" 
than conventional' inheritance, since /they can perform M ' 
arbitrary transformations on the values! .. ' ' v • 

As with the. graphical objects themselves, constraints' • 
can be. defined interactively using' various editors." - 
Lapidary provides some-iconic menus for defining the 
most popular" CorisiraiM^^Figure^S), We have found 
that these are sufficient for most graphical applica- 
tions! Formore complex constraints, a spreadsheet-- * 
lik^interfaqe, which is calieq/C32/ provides a number^ 
of features to help programmers who do not know the h 
exacf syntax [19j. : For example, C$2 has menus that 5 * 
will insert commonly : 'used furictiohs^ -Also, the user 
can point to : objects with ^-ffie..moui^"ahd C32 will iif- :Fa 
sert a reference. into .tfie constraint using the correct" b 
path expression. Of course,; it also - balances paren- ^ 
theses. In the future, .vye ; will ' explore : automatic ih-^f .' 
ferencing of constraints, as; was'dorie in Peridot [1 4]*]\~ 
We envision that when "guessi-hg?v -mode is turned 
on, the system will try, to find; a. lijcely 'constraint be- '/ ' 
tween the newly drawn object and the neighboring" / J 
: objecrs/' : ;// ! T// : ' j; '://.. . • 

The performance of constraints in Garnet is quite fast/ • 
Evaluating constraints ; is not much slower than the- - 
calculations' the programmer would ;hav6' to perform * 

'.a^iyway.^ ;Oh;a^^ con-^ ^ 

sfraint evaluation : (in Lisp>ukesf UO -microseconds-.^ 
This means that objects tracking-the mouse can afford" " 

-to have dozens of~constraints - being re-evaluated for * 
each ^incremental, .mouse, movement.- ... Thc : system' 

. caches jold values for constraints, so ones that do nop " 
change. : value are not Vi re-ev.aiuated. .JVYe .have dis- 

. ^^r^d t .-tb£t t .^e prim atry performance problem with 
constraints is . not speed, but rather space. For each v? 

..constraint .there must. .be .pointers, from slots that are f r 
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' ' - Figure 5: ;l 
The dialogs-boxes from* Lapidary {15] 'that allow "the most 
^WP.QnLCQnstrain^tp be set. ^The rnenu on the top is for 
.^■reptapgular objects (which, mqludes. circles and aggregates), 
5 n ^..^5 on'e'pn ih^ is ^tor'attacHifig 'lines to each 
--other or to ^rectangular objects/ For the t?ox constraints, the 
ocolumnrof buttons "labeled' will caqsevthe" 7 dependent 
-object to .be: .on top of the other object,; just inside the other 
object, centered vertically in the object, just abpve. die other 
; object,' or just below thef other object Similarly, the row of 
? buttons labeled ; ;/e/ir determine uie;-horikontai relationship. 
The button on the bottom comn*ains/the:widui,'and.ihe one 
on the right constrains the height. The text fields, like 
o.££se t t ; and scal.e,ai;e used to-supply parameters to the 
constraints/ ForJines^ eijiier end of the- line 'can, be attached 
'to vanoW^ 
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.referenced to the constraints that use them, and from 
constraints to ; the. slots they reference. We observed 
that. many of the constraints are ..only used once when 
the object is initially placed, so_ we. devised a tech- 
nique where no, memory is. allocated for these con^- 
straints. This .has been enormously effective, and • 
decreases the total run-time storage requirements of 
applications on average by about 50%. For some 
dialog boxes, like the color selection palette, 1500 . 
constraints are reduced xo only 1.00. ; As; an example : 
- of a large scale application, 6690 constraints (which is: - 
over 40%) are eliminated from. the'L.apidary graphical 
editor.- > ■ • . * ; . ; — 

The use of constraints provides the programmer with 
a number of important benefits... The most obvious is 
That the system maintains the relationships. among ob-, 
jects that otherwise would-be the responsibility of the 
programmer. More relevant'to this paper, however, is 
that constraints allow .objects to. provide an abstract. .. 
interface through : .tqprlevel variables, . ..and the .-,*- 
programmer can declaratively specify how- to transr. 
.form the values .for all. components.. Ta fact,, if you 
need to use methods, constraints ,can even be used to^ 
.dynamically determine which method, to, use for a, : 
message based on the current state. , ,This works be- ; : 
cause the value of any slot can be computed using a 
constraints and- the. value returned can- be a function. 
However, we do.. not know of anyone using this fca-' 
•ture.^ \ " * • * • ■ " V : 

is. Input Model : . ; 

Virtually all toolkits, graphics packages, and window 
managers use the same input model: a stream of inputs v 
event records is sent to the. appropriate window. The. : 
application. .program is, expected- to de-queue these \ ■ 

: events and-imerpret them*: Garnet uses an entirely dif- 
ferent model, based on encapsulating input behaviors J 
separately from the graphics [16, 18]. i: This handles - 

-all- ■ input r so objects never -need . event-handling - 
methods. • ; " ' ♦ : • • •••• "• ^ vr i, 

Giamet .provides seven' basic*/ 'Interacted" objects that 
handle, all of;the most common direct Manipulation - 
behaviors; * The.Interactor objects.. in* Garnet aire com- 
pletely independent iof^any graphical representation, - ■-* 



and are purely input filters. 3 ' The- seven types of Inter- 
actors- currently in Garnet are:- • . 

Menu-Interact or - Used to select one or more 
from a set of objects. This can be used for menus, 
radio buttons,- check boxes'/ simple push buttons, 
and the , arrows 1 on scroll bars. -In addition, this 
can, be used to cause application objects to be- 
come selected in a graphics editor. 

Mbve-Grow-Ihteractor - This is used to move 
-an. object or one of a set of objects using the 
.mouse. There maybe feedback to show where 
the object will be moved, or the object itself may 
_ . xnpve with the mouse. This Interactpr.can be used 
to implement- the indicator for one-dimensional or 
two-dimensional scroll bars, and also for moving 
application objects in a graphics editor. v - ; 

*?New--P'o : int-Tnteractor i " - This is used when 
one, f two or an arbitrary 1 number of new points are 
: ■; .desired from the mouse. 

' Angle-Tnteractor - This is used to get the angle 
> . the mouse moves around' some point " It can be 
-. . used; for circular gauges or for rotating objects. 

''•'Trace-rnteractbr - This* is used to get all of the 
. : points -the mouse goes through- between* start and 
• .• *~ end, events, for juse in free-hand .drawing; - 

••'Text-St?r-ing-Intefact6r- : -This isused to edit 
■k text Land- supports rsingle-line, or multi-line and 
multi-font strings. A key translation table -allows 
arbitrary mappings of editing operations. 

Gesfeure-Inieractor Thir supports freehand 
gesturing/ like drawing an "X" on top of an object 
, to. delete it.- ; . 

.;. Unlike, other -implementations, of the Model-View- 
Gontroller idea, ;uv -.G.ametr the ^programmer mever 

•needS;to create new kinds of V controllers/* It is only 
necessary to create an* instance of a pre-defined 'Inter- 

i actor and to . supply a ^ few -.parameters. . An important 
reason that -this works, is that * we have carefully 
chosen the parameters. so that they^ support the full 
range of direct manipulation interfaces. For example, 
the ■ designer, xan specify. -which -mouse button or 
keyboard key causes /the Interactor. to start operating, 
and which causes it to stop. Menu-interactors can be 

: told whether single ormultiple "selections are desired. 
The 1 most important 'parameters r however, are the 



t . 3 I^pte that this use pf the term. '.'infractor***- is different. from 
Some other' systems that use'thVterrn for an eruire widgei 
(graphics plus behaviors). In Garnet, Interactors have no 
graphics,, only behavior. 
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graphics that ihc Infractors operate over. We have 
'•: observed- -that .although direct-manipulation interfaces- 
vary widely in their "look," they 'are m'dstf ^identical" 
in their '/.feci; ' or behavior. Therefore,, by separating ' 
the behavior , from th> graphics, and including " 
.parameters, for -the most .popular options, virtually all : 
behaviors can be. provided* without requiring new 
. "code. I - ,i - - . i 

. . For. example, to create, an Jnteractor - which moves- 
' ground any of the objects which are components of ah^, 
' "aggregate, cahed my-a.gg, the -following- 'is all that as/, 

--needed.:" ' 1 - • • . . ^.- v . 

-* _ ■ -{ credU* - „ iiii d'ice '* my -mo ve r :,i M oV e- G r o'w-I nteracior 

:X ! e e d t>*'c; V - n h j ny, -:f e e dBa c rect) V 
... t.:,sLd:ywh^re * { : el emeriL - o f -my-agg) ) J 

The .-rest of the properties. of my^mcver-will use the' ' 
, default, values (start .on left .burton ;down, move ttid :; 

object mhcr,than grow iu etc), . After, it is created; 

my-mover will coiuinuously/;watch >for a mouse- 

leftbutton; press over any. of. the objects in rny-agg. 
.Wheri : this happens, j.t : will make .-.the .feedback object'" ' 
^(my-leedbackHrect) visible and' begin moving it 
. ip ;/ foUo\v^ f the ? -mouse; until the mouse -button is ; '"~ 
-.released, ;-. Arahat, point, the. my^-feedback-rect'' v 

will ^become .invisible arid the;' actual'" object will be' c 
: ; m .9 v P^ v (If no : feedback ; object had- -been supplied;- • 
-ihenrihe element.: of:vmy-a;goy would -.be directly-- 
/dragged'by the' -mouse.)- ".. ; * 

There, is a standard protocol, through, which .the Inter*?;.?: 
actors ...interface to ;,the : graphical .-objects. The 
move-grow-interactor sets the -box slot of 
-•objects; and the : lef t -ahdS top slots would-be tied 
.to the.:- box- slot .with™coflsirain£s. ( This : allows there;--.; 
tcr be arbitrary Tiltenng'-without -the- Interactor- Raving tre. 
:to-kno\v about' it.. To find- which object- is -under the/; ^ 
mouse./ the Imeracior-" sends, a ..message- to "the ag--;c> : 
-gregate. This/ will Jr in. turn/send messages to-' each of".: 
Jhe components/ However, the.programmernever has?, ■ ■; ; 
to .write, mcthQds;fdr?th'ese; "since: alT-graphical- objects: , . ; 
rare -created -by combining ths Garnet primitives which--.- : 
:supply-the appropriateimeLhods. . \ r- - *.£ : / S 

The Menu -Interact ox. has two -,protocpls: it can; : . : -;: 
ctake.a .separate feedback object as r a parameter; or It 
will directly modify the object that becomes selected.-...- 
If there is a feedback object, then its :obj-over 
slot is set to the object that* becomes selected 7 The 
feedback object' is ; expected ' to "have' dpnstriinis that 



will cause the position and size to depend on 
■■ whatever object is set into the r : obj-Sver slot. For 
r - sample, the left formula might be" fgvl :o bj- 
y b ve r : le ft ) ; which will make the feedback object 
have the same left 1 position as whatever object is 
selected. Notice that the 1 Interactqf does not need to 

• know whether the feedback object is a simple XOR 
rectangle or an aggregate containing squares that 
serve as selection handles. * " 1 ' . 

• If : there :is * no feedback ■ object, - then the 
//■ menu-interactor sets the -^selected slot of 
vv- the. object -itself/ There might -■ be' constraints that 

change position, color or font based on -whether the 
object is selected or not. For example, to implement a 
Motif-like pushedMn ! appearance; for the button of 
Figure 6, the color of the : l top- edge might" be com- 
puted by the constraint: ? " - r * : ' - " : - 

-," (i'fMgvl parent : selected) L "'- 5 ".-.'"': ' 

black r^ihen case.. .« . ■ ■ 

white); else case ' * 1 * ' % - ( 1 . 

'•' The 1 foiTnula- on the- ^bottbm-e'dge^wpuld .be the 
'opposite; andf the color of the' fill-inside would 
' choose between gray and dark-gray; Note that this is 
•* all- perfonTied 'without methods: the parameters'to the 
' : IntSractCKis : are'vaiiie's xri slots;; and the 'interface be- 
>j tween-\the^Int^ j s 
- 'tiirbugh setting weIl^defined*slots in the graphics. 

; :.It:is always legal in Garnet 'to ."set a slc't's value (the 
. slot .does nor have-to; be: pfe -defined). . 'Therefore, if 
the progiMmcr does not want anything td'happen 
when the./pbject becomes selected, he or she can 
simply not attach any constraints' to the slots. THere is 
; -ncven..a worry-of a ^ t Message-ri6t- ^ unde^sttD0cl v, error 
as in a conventional class-instancb systetii, where the 
programmer; would • have 'to deflile' r ah-^ '-appropriate 
i method at'^ rooted sure 
that. tlicre^Ayould, never be a' run-time ieirro'r if -arbitrary 
- • ^objec^s' could be; seleaed. ^ • : r^.r .•: 

: 1 Since, .InteractQrs -can. rbe^-sr^cified by filling in 
parameters/ it is easy to create them irr interactive 
editors. For example, Lapidary provides a dialog box 
for. each Interaetor type .that, allows: graphics to be at- 
sj-ached ^and- rjanameters: to. be set..- : -This': ■ ?.s 1 how 
; -jfcapidary. aliaws arbiu*ary; behaviors tofbe connected 
; ctc-appljcatiQn : speeific ;graphicsrinr.eracuyel>?, without 
requiring the programmer to write code. Interactors 
can be added to aggregates, so the single 
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I Figure 6: 

The button of Figure 1 can be made to look like it moves in 
3-D by changing the colors of the parts. The Interactor 
,does not need to know how the. button responds to becom-- 
ing selected. / - , ^ . r . 



create-instance call will .create; the graphics 
and Interactors necessary for an object to. behave- cor- ■:.« 
,,-iectly. ^ , \ . i 

We have found the Interactor model to be extremely : 
/effective. /This model makes it much easier to , 
^program direct manipulation interfaces. However, we 
'Hiave found a few cases] where the built-in.parameters , 

are not/sufFlcienL , .In this case,.; it f is possible for, the., 

pfo^rnmdr to Write methods'to filter r the data. Typi-, v 
„cally, these "are used when 'custom, .processing is ./: 
J : hj^edv^heii the. . jGbterstptpr , starts, , ^to'ps f pr aborts. ,/ , 

£ven when 'this is required, however, the interface, the^.' 
. programmer sees .is. still- higher-level than conyeri:- : . 

tional event-handling. Details are available elsewhere .., 

PO]. . . _ - £ 




'< - • " Figure 7:" " : - r> ' : 
A simple -editor. .Box . 3 has been selected by'the user, and 
the current line-style (shown on. the leftijs*. thin line. 



7* Examp / : ! 

*r T To give~*an example/of the:;style of programming in 
'/•Garnet^ the toy: 

^graphics editor in/Figure. 7 and compare \V with the 
- - impiemeritation r in ; conventional -object-oriented lan- 
: : guages; Here, ; every time the user ' clicks" with the 
right mouse button.in^the drawing window, a new box., 
and ~ arrow is created ; using the current line style 
; ; (which iS; shown on the'left): The;arrpws Always go to 
the previously-created -box. . Thausencan click with 
the left mouse button to select objects, .and the 
handles appear. Dragging a handle moves or grows 
the selected object The Delete Dutton deletes the/ 
:. selected, object, and pressing, on a new line- style while 
an object is .selected causes? the; object to Change. Of 
course; much of this program could; be created using 
'■^ the Lapidary .^graphical -editor" 1 without "writing any 
' ? code, »but we wilT assume here" that- Lapidary is not 
i ^being-used, and the^programraer wants ttf Avrite every- 
■ thing by hand. ^ ■ 



" To implement' this'jn Garnet, the programmer would 
'first create_prototypes for the two kinds of .objects that 
can be created: an'arrpw, andean, aggregate containing 
'. / a rounded-rectangle arid : a text r object. .The aggregate 
/ will contain .constraints : thit keep the xexL centered at 
the top of the rounded rectangle. .Then,, a^main win- 
dow would be created- containing the ; buttons for 
/ delete, and ' quit v and four line objects , to serve as a 
" 1 paleue. A rectangle would, he _ ; addpd to show which 
_'line style is : Velected,.,and.a menu-interaeior would be 
i/„ attached to the; four lines f , with., the rectangle as the 
.j,. feedback.^- v - - :,r\:x 

To allow new objects' to be created, a New-Point- 
Interact ox. would he added to tl}e right part of the 
winciqw which .starts, on -the right button.. -A parameter 
..jo- this interactor is: the prototype; from :: which in- 

/ : stances .will be created. Here, this slot will contain an 
aggregate containing- the prototype, box and arrows. 
Formulas in,the prototypes will- cause the arrows to 
have the appropriate end points ,and the.string to have 

. , the appropriate value. ., . - ^ - - ; - ; . 

" To make the pbjects^'electable, it is only necessary to 
include / the " pre-defined '...§ele ct ip.h-handle- 
widget, which displays 'the square? around the ob- 
jects and allows objects to be resided and moved. In- 

- .-temallyy this widget" .contains ^m^y : formulas that 
cause the squares to be attached to the objects at the 
appropriate places (it works for both boxes and lines). 
The . value, of the selection-harxdle widget is the 

/ ^elected : pbj(iet ~ wh will he ~ accessed by the call- 
back functions for chahging^the line-style^and delete. 
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To compare the Jmplementauo.ns^we asked a number 

- * of people to* implement- the same 'editor ;in different 
-object systems and toolkits. . Most;pf these people 
were the designers of the toolkits. ; 

One implementation was " in GINA++, ,a research 
toolkit in C++ from trie German ; National Research 
• ; Center for Computer Science. 4 Trie-implementation :: 
defines classes for the line-style palette -items, for- the. 
commands for creating and deleting objects, fdr'tKe"' 
graphical objects, and for the editor and its panes. 
Methods on. the graphical objects include-setting~anci 
accessing the "to'V^and "from 1 * objects (for thekr-^ 
y rows),; drawing, and-' drawing- with* dashed outline- to- ; " 
•serve- -as a feedback-object ■ Method's for the editor 

- include creating the -windows,- and -accessing and set- 
ting the current line-style and the selected obje'ci: :; "~ 

. ' GINA++ provides a rejaihed'-obj^c't model, so : *the ; 
programmer does riot need to write erase or redisplay ' 
methods/' Siippfort for selection 'handles around a rec- ; ; 
lingular object Is' built. in; but the programmer over-' - ; 
y lode the ^Iectidn : draw : method for lines to' only shtf^ mi 
[t riddles 'at ' the end -points: ' To. handle* creating n : ew ::v 
objects, when &INA++ sends the bbttbn_press" tJ 
■ message to the background wihdo^;lhe^CreateiBV' : 
. object" is ; 6reied:;-^This specif command object 
^defines methodk td ;r han'die the* incremental - feedback Wv 
-when dragging' out 'a' new" box, Vnd'thenf treating a 
new rounded-rectangle and a new : afrovr when the 
mouse button is released. 

CLEM [11] is a popular ^mmerciaF Lisp 'toolkit th'at v^c 
• uses CLOS, "the standard : <j&mmon Lisp object sys- : ■ • 
•■t&m.- Like G^et r jeLlM supplies a retained object I- 
-model with incrcmentW redis^ they call ' ' 

streams' ') ■ and ' high-le^el B input - handling (called^ - 
'"a^lators*^^ declaratives ^ 

-mechinisrn 'for 1 defining the : window y iayout; but not"-: 
for object definitions, so the programmer wrote draw-- 
methods for : t2ie objects and selection handles. The 
prognLrnmef 1 also had to^vynte ah event* handler for the. - 
^^? or ? ^r ot >j ect ?/ sinc ^ tiiibiie is hot 'an' appropriate* : 
*'t^^^slatb^. ,, : \ ' : ;' : " tJ ' h - 1 

In both GMA-Hf and -ClIIMv methods are riebded for,. 



- drawing objects, since they cannot -be specified 
t declarative^. How the rectangle; the text is displayed 

* is hard-wired into , the draw method of the box class, 
and' thus 1 it might be harder to modify than in Garnet, 
especially by interactiye-pirograiTis. Because they do 

• not have constraints,^ the cbde must explicitly redraw 
the lines and the text label when the box is moved, 

- whereas in Garnet this is handled- automatically. 

■ As a small measure of 'whether the Ganiet technique 
is more effective, Figure 8 shows the coding time and 
size information for seven implementations of the 

s editor in Figbre 7.' 'AD but the MacApp one was im- 

1 ' : plemented by one of the designers of the toolkit, so 
you can expect that they knew the systems 'well. The 
MacApp implementor was. also an expert with his sys- 
tern.' Zdrava is an. experimental, unfinished system, 
scTthe 'times for it are simply estimates frdrn the desig- 
ner, 'Of bourse, these;nufhbers\ constitute a 

; scientific sttody, arid'fthFoiher programmers did not 
« ^1°^ that ^^y^^^^jP^^c^'^ing' iri a time tesL Fur-: 

V. F 1 ?" 710 !" 6 ! "?, x .F^Pl e was chosen by the Garnet 
desl^fcr: M that graphical 

'^prpgram's;cSn be^ Smaller knd. written" faStePiri , Garnet . ■ - 



System 


Language 


Time 


Lines of Code 


Garnet . 


Common Lisp, 


•2.5 hrs , . ; , 


, :lS3slines 


CLIM+Zdrava 


Common Lisp 


23 hrs (est.)" 


"I90lest.) 


CUM - 


Common' Lisp 


'4:5 hrs " - J 


'331' lines 


MacApp" „ .;■ 


Obpct.PascialT 


9^te- . • r>> 


f 1026 lines 


GINA-w- - , , 


C+-F „. :v 


16 hours.- . 


. 550. lines 


Lisp View 


.Common Lisp 


2 days . , _ ... 


. SOQ.lines 


CLM. GrNA 


Common Lisp 


2" to 3 days ' 


273 lines 



" For moTe information on 0lNA-r+ 'of CLM/GINA for Lisp - 
; contact Mike- Speriie, PiO. Box ; 13i6, : D-W-5205 St 5 Augustin 
.Gemujiiy, -f49 2241J4-2642; spen]cc@gmd.de. m i • " : ■ ; 



- - r . -\ ^Figure 8: - f ' r - :' ; :-* s;fv. 

y -Times and code size to create .the editor of -Figure 7 using 
, venous sys^erns. CLD^, ^nd . GINA , are 'discussed in the 
" ^article. MacApp is "a commerclai product of Apple and 
- 'L^sjpView -is : a : cbmmerdal'prcduc - - : 

8< Modularity : : . , : ; , : - 
- Some:pcople claim ihat- using ynetliods-.i^a -better in- . 
n.terface.-to: objectsn/because; At 'supports ;bener infor- 
r t :mation hidingr, The motivation isJLhat the internal im- 
. plementatipn of -the object can Jbe^rnore easily changed 
•/if lh^ interface is. thro]a-gb methods. - Therefore some 
.ipbject systems,, such ;9s>S£LF [5]-, <3o,np| gllow direct 
access to any object variables, but : only -p^vi<Je access 
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through -methods. - Garnet takes an opposite' approach, 
and the mala interface is through the data of objects.- 
However, this can, be just as modular. 

8-1 Data vs. Methods • 

In Garnet, -an object advertises its input and output 
slots, and most objects of the same type use the same 
slots (for example, .all, graphical objects have : lef t r 
:top, : width, : height/* v : filling- - 
style/ , etc.). . This .corresponds to. advertising the „ 
exported methods, in other object-systems. In Garnet, 
through the use of constraint ■ formulas, objects can • - 
transform the parameter -values -in -whatever way : is,, 
desired. For cxample i; the Menu-Interactor sets — 
the : selected sloi of objects.- It is up to the inter- , 
nal constraints in the selected object what this does* if — 
anything. The color, position,- or font of the object : 
might hayc^a-rformulaidepcnding pn.the.:.selectf.d.- - 
-slot; and the Intcractpr does not care.. This -interface is 
just; as ...modular as ;ir the-. Interacior called a generic 
Becpme-Selected method.- 

Although., Gamei: does not .currently, .provide .;, 
mechanisms, to declare which slots of an .object can be ( ... 
used from outside and which are internal, this could- ;0 
easily be added. This would provide the same protect,, 
tion as class-instance rpodcls whiqh have public and u - :! 
.private methods. . i : ; t v , V /J 

812 Constraints . vs. Methods . 

'Cpnstrain.ts„.aiso contribute- to modularity in-.another x:t , 
way,, by "fixing a flaw, in the conventional, imperative-;-:* 
object-oriented, model, in the conventional model, to 
achieve certain types of behavior, the. program mer- 1; 
must either explicitly arrange the' methods so they ex-;- ;- 
ecute in the proper order, thus violating the • • 
modularity ;of objects, or else allow . the methods to 
.execute in. -an arbitrary order, thus evaluating methods- ■ 

.more times than necessary, and" possibly-. destroying; . • 
the correctness of the program if the'methodS' commit.;. 

/side-effects.' Fonexample, suppose' that^programmer r.. 
wants to keep a box called A centered above two others • 

* boxes called B ahd*C ^Rgure- 9). In' a conventional 

; system;- ; the*prograirimer might add' a r message to the..! 
move -methods -in B and C that calls a "centering 
method in A. Later the programm ef decides* that C 
should always be 20 pixels to the right of B. The 
programmer thus expands the move method in B to" 1 
send a message to the move method in C. Without- 



proper sequencing, the centering-method in A may be 
called twice, once by the move.method in A, and once 
by Lhe move method in Br. However, the centering 
-method- in A should only be called once, after the 
methods .in both B and C have terminated'.' 




~ Figure 9: ~" *' 

A box centered over two .'other boxes. J£ either box B or C 
moves, box A should move so that it stays centered over the 
boxes. . . - - , , - ■• . ■ 



In this'caseyttie programmer is; faced with 'two" equally 
" "unpalatable chbices. The programmer can choose not 
/ to prbvide^'expiicit sequencing,.' in /which case the 
:X centering method in A may execute twice. This is both 
yi wasteful" and 'potentially' dangerous if the centering 
method commits side-effects (in this case it probably 
would not, but obviously there are situations where 
this could pose a problem). , Alternatively, the 
J 'programmer .could rely on the fact thaj: the move 
method in c' calls the' centering me ^iod in A, .and thus 
„not call the centering method itself. However,/the im- 
plementation of the move method, in B now depend on 
the implementation of trie move .method, in c % which 
" ' '.violates the notion of modularity."' , . 

■ "Notice that in either "case J the modularity principle is 
'■additionally violated becati'se B'ari'd 'C have- to know 
:s that A depends on them (kndlat^r'B "has' to know that 
r,t 'C 4 depends" on it). u If the' centering relationship be- 
" 1 'tween A, B, and' C is later destroyed,, hot only must the 
'centering method" : in A be deleted, but the move 
"methods in 3 and' C' must be_c^pged-ag"welL (A 
■*"' u similar 'situation arose in the exarripje 'of Figure 7, 
where the ' conventional "systems put code in the 
. ^methods- of .the^boxes tqjnaintaiii.the linesO- 
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In a •.consLrainL-driven 1 language; neither of these 
■ problems arises since the constraint solver handles 
both communication between objects arid the ordering 
of constraints. ^ In the above example, the programmer 
would initially; write a constraint ' that centered A 
above B and C. Later the programmer would add an 
_ additional co^trajnrpj acing/c 20 .pixels to the right - 
of B. The constraint solver would automatically en- 
sure that the constraints were evaluated in the proper 
order. Thus the programmer would not have to worry, 
about sequencing. In, addition, the move methods for- 
B and C would not have to know about the relation- 
ships among the three -objects (the constraint solver'^ 
. would- be responsible for propagating the change "in* 
formation), so they 'would simply modify the local ■ 
" state of their object. If one or both of 'the constraints ■ 
. were later. deIeted,jhe,moy.e.-methods.wo,tild 1 not have ^ 
to be modified. .Thus constraint-driven programming'-' 
■. . better preservesc'hemodularity of objects. ■ '* 

8.3 Interactors vs. Methods 

-The -Garnet input - -model—- -also- - provide better 
. r . modularity ; thanjound in othpr systems. , The graphics" 

: ^ ^^^M^^^t of 't^.c^behjaviors, .and they 
. .^,1^ develop^ othcr^- 
, systems, mod^is v y|eW$ and'ront^JIcrs have' always^-' 
. . ^n^ughUy' coupled^ they. alLhadVto .be. carefully^ 
.'/modified together,""* t . V '/ ~ 

• 8i4 ;Re«iise ;' ? : : ; : v : ' V" """V?' 

Andtherkey feature of Garnet' is .that it provides better^ 
' sdftwar? ' re-use than most"' other 1 toolkits.; The'" ~ fi 

'program^ n?w even ^ 

' /handlers; since' Ae/buiit;in' Tnteractors are sufficients^ 
' The programmer does' hot need * to deal with window 

refresh or' maintaining re^ 

since the object system* 'and constraint solver' handle- 
.this,. In. addition, since, we can : be.sure that. there is an~'- j 
: object i^.^mo^Xpr every object on the-sereen, it is" '' 
. possible to provide ^ the - r " 

. v selection : h ^dles". ~ " The 'handles ' contain constraints ■ z j 
. that, referenqe/.the^ selected objecL. Toolkits without. I;-' 
, refined objects cannot' : suppjy r .*selec.tipn^ handle- 

widgets tecause they/" would . need "to.." access the"' 1 -■ 
. aj^li^tio&^s .,;nternaf " data.. sLruct-iire". ip ..know [ where ' 
Objects are and hQw to* ipovt and grow the objects. 0 

Another feature of Gkmet fs' thal,* if the programmer- £ 
wants to make a slight modification of an existing ob r/r ~ 



, . ject, it- is only necessary to' spccijfy the- specific 
■; changes to the graphics, rather than having to write 
completely hew draw methods. " ' :■"?.*. 

9. Conclusion : 

The style of programming in the Garnet object system 
' - is quite' "different frorii other "object systems: the 
programmer collects together graphical objects, writes 
-constraints to define the relationships among them, 

- and' then- atiadhes- instances of pre-defined" Interactor 
objects to -cause the objects to respond to the user. 

- Usually ,-much of 'the '-programming'-*: can be done 

* ' with graphical; interactive tools; rather than by writ- 

- ing code. - Even* when not using interactive tools, 
programmers -rarely write methods -when L creating 
Garnet code. Our experience suggests that this style 
of programming is much more effective for graphical 

' s»user interfaces. ■ -It would- be- interesting to see which 
; " other types- of programmihg-'ir- For 
example, object ^nehied ; ' data bas'es-seern like. a good 
candidate, sincc-they clearly use a *4retained-object 
model/' and a primary use of methods there is to up- 
-date- objects and to' maintain ' "'consistency among 
various -objects: 5 Many other application 'kreiis might 

• also'-benefit frdrri this 'style/of prbgr^mjng;' : ' f; 
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